During decryption, cacert, cert, key (and url) are all extracted from the JWE protected header and fed to curl (line 115) before the AEAD integrity check at line 128 (jose jwe dec). The url field was already consumed unauthenticated before this patch, so this is a pre-existing design property of clevis-tang. However, cacert qualitatively extends the attack surface: an attacker who can modify the stored JWE can now also override which CA curl trusts, enabling MITM against the legitimate tang server with a self-signed cert planted on disk. Previously, modifying url alone still required a certificate trusted by the system CA store.

The practical exploitability is limited (requires disk write access + network position, and the ECMR exchange value alone does not reveal the decryption key), so this may be acceptable as a known trade-off.

Worth considering: validate that cert/key/cacert paths are under an expected prefix (e.g., /etc/clevis/), or use indirection (store a profile name, resolve to paths at runtime from a fixed directory). At minimum, document the trust model explicitly so users understand the implication.

Thanks a lot for your review! In my understanding, if attacker could modify JWE header, they could probably also modify the ca trust store in /etc/pki. If this is correct, cacert does not add more security risk here (correct me if my understanding is wrong). I also thought about adding validation for cert/key/cacert paths, but considering this aims to be used generically, it is hard to add any specific cacert path validation so I feel path-prefix validation felt too restrictive here.
I added one section named "mTLS SECURITY MODEL" in clevis-encrypt-tang.1.adoc to describe the potential risk of cacert and recommende that the CA be installed in the system trust store (with cacert omitted) where possible

The wording here says the mTLS properties are stored "without authentication", but they're placed in the JWE protected header (lines 193-195 of the encrypt script), which is the AAD for AES-256-GCM per RFC 7516 Section 5.1. Modifying any field in the protected header causes jose jwe dec to reject the token.

The real subtlety is that clevis-decrypt-tang reads and acts on these values (the curl request at line 123) before the AEAD integrity check runs (line 136). So tampering is detected, but only after one network request has already been made with the tampered parameters.

Would something like this be more accurate?

When cacert, cert, or key are set but url uses http://, curl silently ignores --cacert, --cert, and --key. Encryption succeeds, the paths get baked into the JWE header, but all traffic goes over plaintext. The user thinks mTLS is protecting the connection when it isn't.

Would it make sense to reject this at bind time, similar to the key-without-cert check right above?

if [ -n "$cacert" ] || [ -n "$cert" ]; then
    case "$url" in
        https://*) ;;
        *) echo "TLS options (cacert/cert/key) require an https:// URL!" >&2
           exit 1 ;;
    esac
fi